| Just to be helpful, the way to do it more safely, without massive | need for checking is to build a complete mail message, including | header, and hand that to "sendmail -t" which then reads the recipient | information out of the constructed header. [Sendmail should of course | be an invocation of smail or pp, not the BSD program of that name, | given the history of problems that has had] I suspect this still wont take care of emails to pipes or files, i.e <|/bin/sh> or </.rhosts>, it is a legitimate, albeit unexpected, mail-command going to sendmail. So unless these two mode are totally stripped out of the sendmail, there will exist a vulnerability there, wont it? A picture: +--------+ | WWW- | (producing input to a textfield | client | in a form, namely the textfield +--------+ recipient. Content <|/bin/sh>.) || || (outside) ...................................................... || (inside, running as nobody) || // // +-----+ (funneling to CGI script AnyForm) |HTTPD|============+-----+ +-----+ |Scrpt| Creates body + headers //======| | recipient <|/bin/sh> // +-----+ turns into To: <|/bin/sh> || || Body sent to sendmail +-----+ Sendmail discovers |send-| ... spawns a shell that is fed the body. a legitimate req for |mail |=====+--------+ piped exec of mail- +-----+ | o o | Disaster Deamon (tm) body, and .... | ^ | strikes again! | [...] | +--------+ (Ps. This is true multimedia, but without the glossy surface! :-)) I don't know about smail and pp though. The key here is however that it is _legitimate_ requests for _features_ that is the problem, not any bugs. (I usually phrase this as thought-of "pure" data that is actually containing meta-data syntax escapes.) /Christian Wettergren